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NATIONAL FOREWORD This Indian Standard ( Part 1 ) which is identical with ISO 15022-1 :1999 `Securities -- Scheme for messages ( Data Field Dictionary ) -- Part 1 : Data field and message design rules and guidelines' issued by the International Organization for Standardization ( ISO ) was adopted by the Bureau of Indian Standards on the recommendations of the Banking and Financial Services Sectional Committee and approval of the Management and Systems Division Council. The text of the international Standard has been approved as suitable for publication as an Indian Standard without deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention is particularly drawn to the following: a) Wherever the words `International Standard' appear referring to this standard, they should be read as `Indian Standard'. Comma ( , ) has been used as a decimal marker while in Indian Standards, the current practice is to use a point ( . ) as the decimal marker.

b)

In the adopted standard, references appear to certain International Standards for which Indian Standard also exist. The corresponding Indian Standards which are to be substituted in their places are listed below along with their degree of equivalence for the editions indicated: International Standard ISO 15022-2: 1999 Securities -- Scheme for messages ( Data Field Dictionary ) -- Part 2: Maintenance of the data field dictionary and catalogue of messages lSO/lEC 646 : 1991 Information technology -- ISO 7-bit coded set for information character interchange Corresponding Indian Standard Degree of Equivalence Identical ` "

IS 15587 ( Part 2 ) : 2005 Securities -- Scheme for messages ( Data Field Dictionary ): Part 2 Maintenance of the data field dictionary and catalogue of messages Information Is 10315 : 1997 technology -- ISO 7-bit coded information character set for interchange

do

The technical committee responsible for the preparation of this standard has reviewed the provisions of the following International Standards and has decided that they are acceptable for use in conjunction with this standard: /nternationa/ Standard Title Information technology -- 8-bit single-byte coded.graphic character sets -- Part 1 : Latin alphabet No. ~ Electronic data interchange for administration, ( EDIFACT ) -- Application level syntax rules commerce and transport

lSO/lEC 8859-1

ISO 9735 ( all parts )

lSO/lEC 10646-1

Information technology -- Universal Multiple-Octet Coded Character ( Ucs ) -- Part 1 : Architecture and basic multilingual plane

Set

Technical Corrigendum

1 of the International Standard has been given at the end of this publication.
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Introduction
This part of ISO 15022 replaces lSO/TR 7775, Securities -- Scheme for message types and ISO 11521, Secutiies -- scheme for interdepository message types. In the mid-1990s, it was felt strongly that the International Standards for communication between securities industry participants required an urgent review aiming at (1) reducing the time taken to deliver new message types to the market place and (2) improving "straight through processing" capabilities. ISO 15022 sets the principles necessary to provide the different communities of users with the tools to design message types to support their specific information flows. These tools consist of -- -- -- a set of syntax and message design rules; a dictionary of data fields; and a catalogue for present and future messages built by the industry with the above-mentioned fields and rules.

To address the evolving needs of the industry as they arise, the Data Field Dictionary and the Catalogue of Messages have been kept outside the standard. They are made available by a Registration Authority which updates them as necessaty upon the request of industry participants. To protect investments already made by the industry, the syntax proposed in this part of ISO 15022, referred to as the "Enhanced ISO 7775 syntax", is based on the syntax used for the previous ISO 7775 and ISO 11521. However, to ensure the promotion, awareness and knowledge of the Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT), a standard developed by the United Nations, adopted by ISO in 1988 as ISO 9735, and recommended as the International Standard for Electronic data interchange, ISO 15022 also supports the EDIFACT syntax. To recognize that a number of countries are currently.or may in the future migrate to EDIFACT, the Registration Authority shall register EDIFACT fields and messages for use by secutlties industry participants. The ISO 15022 Data Field Dictionary shows how to format each data element required in securities messages in the Enhanced ISO 7775 syntax and in the EDIFACT -syntax. Similarly, the Catalogue of Messages shows messages structured under both the Enhanced ISO 7775 and the EDIFACT message design rules and syntax. .1S0 15022 contains: -- -- -- the Enhanced ISO 7775 syntax and message design rules; the organization of the Data Field Dictionary and the Catalogue of Messages the service levels and procedures for the Registration Authority, including its supervision by ISO.

The EDIFACT syntax referred to in this document is described in ISO 9735. It is expected that this new flexible framework will allow industry groups to build messages in an international language and to migrate to EDIFACT if desired, at the speed which matches the urgency of their needs. If none of the messages recorded in the Catalogue of Messages addresses their requirements, they will be able to agree on the use of a new one and to design it from the approved fields .in the Enhanced ISO 7775 and/or EDIFACT syntax. The Registration Authority will create extra fields as necessary and record the new message types and versions in the Catalogue of Messages to avoid the duplication of effort by other groups who have similar needs. `The Registration Authority will ensure that the new fields and the new ,messages are available in both the Enhanced ISO 7775 and the EDIFACT formats, as required. Straight through processing is expected to be enhanced because each community of users will be able to explicitly define its own business requirements and convert them into market specific message type versions. The approach differs from the generic international messages defined so far by ISO, which did not explicitly identify market specifics and therefore rendered the communication interfaces dependent on additional rules to be agreed bilaterally between senders and receivers.
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Although the new framework permits multiple versions of the same message type, it is expected "that market forces will naturally limit their creation to what is actually required until further convergence of market practices makes it possible to develop true international message standards for straight through processing. Similarly, it is expected that market forces will naturally organize the migration to EDIFACT at an appropriate pace. The dual structure of the Data Field Dictionary and Catalogue of Messages will facilitate the migration -and the development of any required conversion mechanisms. NOTE ISO 15022 has been designed to incorporate and be upwards compatible with the previous securities message standards ISO 7775 and ISO 11521, as updated in iSO/TR 7775. As a result, the initial Data Field Dictionaryand Catalogue of Messages accommodate lSO/TR 7775 data fields and messages. However, some of the previous fields and messages are not fully compliant with the Enhanced ISO 7775 syntax, and none are compliant with EDIFACT. In addition, the initial Data Field Dictionary incorporates the Industry Standardization for Institutional Trade Communications (ISITC) DSTU 1/1995 and the Securities Standards Advisory Board (SSAB) data dictionaries. A list of standards
related to this part of ISO 15022 is given in the bibliography.
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1

Scope
consists of:

This part of ISO 15022

--
--

the-description of the Enhanced ISO 7775 syntax and message design rules; the contents and organization messages, and
of the dictionary of Enhanced ISO 7775 and

EDIFACT

fields for securities

--

the contents and organization of the catalogue of. securities messages built in the Enhanced ISO 7775 and EDIFACT syntaxes.

It refers to the EDIFACT syntax when necessary to ensure an easy cross-reference between Enhanced ISO 7775 concepts and EDIFACT concepts. The EDIFACT syntax is not described in this part of ISO 15022; it is defined in ISO 9735 which is incorporated by reference. This part of ISO 15022 is used for electronic data interchange between securities industry "participants, independently of the communication network. Network dependent rules, for example, on how to specify where and when the message is to be sent, message acknowledgement and message protection are outside the scope of this part of ISO 15022. The maintenance of this part of ISO 15022 is described in parl 2 of ISO 15022.

2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this part of ISO 15022. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this part of ISO 15022 are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards. lSO/lEC 646, h?forrnation kchno/ogy -- ISO 7-bit coded character set for information -- 8-bit single-byte coded graphic character interchange. sets -- Part 1: Latin alphabet

lSO/lEC 8859-1, /reformation technology No. 1. ISO 9735 (all parts), Electronic Application level syntax rules.

data interchange

tor administration,

commerce

and transport

(EDIFAC~

--

ISO/lEC 10646-1, /reformation technology Architecture and Basic Multilingual Plane.

-- Universal

Mu/tip/e-Octet

Coded

Character

Set (LXX)

-- Patt.1:

Reference is also made to lSO/TR 7775, which refers to Technical Report (type 2) 7775. This document contains all message types included in ISO 7775 and ISO 11521, as updated and complemented by the ISO 7775 Maintenance Agency until September 1994.
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IS 15587 (Part 1): 2005 1s01 5022-1:1999 3 Terms and definitions
For the purposes of this part of ISO 15022, the following terms and definitions-apply. 3.1 block of data fields predefine and identified set of functionally related data fields related to a business concept
NOTE A block of data fields is identified by a start of block and an end of block data field which both mention the block name, which qualifies the specific meaning of the block. The block of data fields may be repeating. A block of data fields may

also include other, nested, blocks of data fields.

3.2 community of users financial institutions sharing the same market practice and using the same message standards 3.3 component data element simple data element which is a subordinate portion of a composite data element identified by its position within the composite data element 3.4 composite data element data-element containing two or more component data elements 3.5 data element unit of data for which the identification, description and value representation have been specified
NOTE

A data element in certaincontextsis considered indivisible.

3.6 data element tag (EDIFACT only) unique identifier for a data element in an EDIFACT data elements dicectory (see field tag) 3.7 data field data field consists of a field tag followed by a data item
NOTE .It is used to convey a simple data element or a composite data element which represents a unit of meaningful information.

-3.8 data item expression of a single data element or a composite data element represented in a specific format and identified by the preceding field tag 3.9 data source issuer code string of characters used to identify the institution or market organization owning the data source scheme 3.10 data source issuer sub-code identification of the specific data source scheme for the data source issuer 3.11 data source scheme data source scheme consists of two sub-fields, the data source issuer code and the data source issuer sub-code, which are used in the data field tag to identify a proprietary scheme for the data item
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3.12 discrete data field data field which expresses a specific single business data item
NOTE item. The field tag of a discrete data field does not need a qualifier to further define the business meaning of the data

>

3.13 field tag unique string of characters identifying the meaning, format, and value representation of the following data item (see data element tag)
NOTE A field tag is made up of a field type optionallyfollowed by a qualifier and a data source scheme.

3.14 field type unique string of characters which starts the field tag and identifies the format and value representation of the data item
It also identifies either the meaning of the following data item (see discrete data field) or the class of the following NOTE data item (see generic data field).

3.15 generic data field data field used to express the data of afamily or class of data items of the same nature, e.g. dates, amounts
NOTE The field tag of a generic data field contains a qualifier to specify the precise meaning of the following data item.

3.16 group of segments (EDIFACT only) identified, usually repeatable, grouping of segments 3.17 message series of data fields and/or blocks of data fields communicated from one party to another to convey meaningful business information
In EDIFACT, a set of segments in the order specified in an EDIFACT message directoty starting with the message NOTE header and ending with the message trailer.

3.18 message code unique string of characters identifying the message type 3.19 message descriptor string of characters which specifies the scope of the message and the fields that maybe used
NOTE A message descriptor is made up of a message code optionally followed by a version number and a message version sub-format.

3.20 message type identified and structured set of data items or data elements used to convey information related to a specific business scope 3.21 message version issuer code string of characters used to identify the institution or market segment owning the message verwon sub-format
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3.22 message version issuer sub-code identification of the specific message version sub-format for the message version issuer 3.23 message version sub-format message version sub-format consists of two sub-fields, the message version issuer code and the message version issuer sub-code, which are used in the message descriptor to identify a proprietary sub-format 3.24 nested segment (EDIFACT only) segment which directly relates to another segment in an identified and structured group of segments covering the requirements for a specific message type 3.25 qualified data element data element whose precise meaning is conveyed by an associated qualifier 3.26 qualified segment (EDIFACT only) segment whose precise meaning is conveyed by an associated qualifier
3.27

qualifief data element whose value is expressed as a code that gives specific meaning to the function of another data element, data item, or segment 3.28 repeating segment (EDIFACT only) segment which maylepeat 3.29 segment (EDIFACT only) predefine
NOTE

in a message as specified in the relevant message type specification

and identified set of functionally related data element values

A segment starts with a segment tag and ends with a segment terminator.

3.30 segment tag (EDIFACT only) simple data element uniquely identifying a segment 3.31 separator character(s) used for the syntactical separation of data 3.32 sequence predefine

set of data fields for documentation purposes only

3.33 simple data element data element containing a single value 3.34 sub-field subdivision or subordinate portion of a composite data element or of a field tag or of a message descriptor 3.35 version number allows different versions of the message type to be supported concurrently
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IS 15587 (Part 1): 2005 ISO 15022-1:1999 4 Enhanced ISO 7775 Syntax and lexical format 4.1 Basic principles
Messages that are designed to comply with the Enhanced ISO 7775 -standard and are part of the Catalogue of Messages, adhere to the following basic principles.
--

Messages must be system and network independent. The scope of the message should not be dependent on the sender and/or receiver of the message. A field tag should uniquely identify the following data item, independently of the message type or the position of the data fieid in a message.

-- --

4.2 Character sets and lexical format
This part of ISO 15022 accommodates data fields that comply with the following character sets. -- lSO/lEC 8859-1 (Latin 1); lSO/lEC 8859-1 consists
English, Faroese, Swedish. of 191 graphic characters and suppotls all the characters used in Danish, Dutch, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish and

--

lSO/lEC 10646-1 [Universal Multiple-Octet Coded Character Set (UCS)] This supports most non-Latin based languages;

-- 4.2.1

Binary. Specifying lexical format

.

.

The format of a field and its constituents is documented in the following way. Length restrictions nn nn! nn-nn nn"nn minimum 1 character and maximum nn characters fixed number of characters range of characters maximum number of lines x maximum number of characters per line

Type of characters

n d s h a c e Y z u b
U.

digits digits with a decimal comma + or - sign (if optional, no sign implies a positive value) upper case hexadecimals upper case letters upper case alphanumeric characters blank space upper case ISO 9735 characters (UNOA - Level A character set) lSO/lEC 8859-1 (Latin 1) characters lSO/lEC 10646-1 [Universal Multiple-Octet Coded Character Set (USC)] binary character as-is, or text as-is

/

`lext"
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Many of the data items in the Data Field Dictionary can accept lower case letters and other characters as well as upper case alphanumeric characters. They are of a data type z, i.e. they may consist of lSO/lEC 8859-1 (Latin 1) characters, which is the same as EDIFACT code list UNOC. Some networks do not support all these characters. Acceptable subsets of Latin 1 include: -- lSO/lEC 646 With US national option. This is a 7-bit character set. The printable codes from 32 to 127 are identical with Latin 1. EDIFACT code list UNOA - Level A character set (existing code `y'). This is also the International Telex Character Set. EDIFACT code list UNOB - Level B character set. Upper and lowercase character set. letters.

--

1s0 9735

-- -- -- 4.2.2

1s0 9735 S.W.I.F.T.

Windows code page 1252- Windows Latin 1 (ANSI) is in fact a superaet of lSO/lEC 8859-1. Separators are required to syntactically

In addition to the character set used for defining data fields, control characters separate: -- -- -- data fields within a message (field separator); field tag from data item (tag separator); sub-fields within a data item, field tag or message descriptor (sub-field separator).

Similarly, if it is required to include a control character within the text, it must be preceded by a release character to signify that it should be regarded as text. The release character itself -should also be preceded by another release . . character if it is to be treated as text. The defined separators and release character are: -- -- -- -- Field separator Tag separator Sub-field separator Release character CRLF (carriage return-line feed) ":" (colon) (when not followed immediately by another ":"), or the second "/" after "::" `/", or "::"in a field tag "?

In addition, the end of a message is marked by a message delimiter. The format of a message delimiter is CRLF "-" (carriage return-line feed-minus sign). For an example see 4.3.2.1. 4.2.3 Notation used

The following notation is used to describe the use of sub-fields, data fields, sequences of data fields or blocks of data fields. It is also used to describe the structure and use or format of data fields and messages. The name of an item or a collection of items is often shown in"< . ...>" (the e and > characters do not form part of the message). If a character or sub-field is optional within a field, it is shown in square brackets "[.. l". (The [ and ] characters do not form part of the message). Alternative items, i.e. one item to be used out of a series of items, are shown .by separating them by an or sign "l". (The I character does not form part of the message.)

IS 15587 (Pm 1) :2005 1s0 15022-1:1899
The following examples EXAMPLE 1 illustrate these points:

P!z[ln] means a field which is either 2 acceptable Latin 1 characters long or 2 characters "followedby a digit.

.

EXAMPLE 2

3!c('7''3!c~~8z]] means that the format can consist of three parts (sub-fields) which are separated by"~ characters, and it may.consist of: sub-field 1 on~y sub-fields 1 &2 or sub-fields 1, 2 & 3 3!C 3!C''7''3!C 3!c"/''3!c"8z8z

In this example sub-field 3 may consist of any acceptable Latin 1 characters whereas sub-fields 1 and 2 can only NOTE consist of upper case alphanumeric characters.
EXAMPLE 3 EXAMPLE 4 <A>I<B> <A>[<B>[<C>I<D>J means either sequence A; sequence A,B; sequence A,B, C or sequence A,B,D.

4.2.4

Defining numbers

Numbers are frequently specified as format d. This format requires a decimal separator (i.e. a comma) to be always specified, with at least one digit before the comma. Leading and trailing zeroes are acceptable. Valid formats include: 123, 00123, 12,3 0,123 123456, 123,0

The following are invalid formats: 123 123456, 4.3 Message 12.3 123.456, structure .123 123,456, ,123 . .

and design rules

.

This clause describes the various components of a message, and how they maybe combined together. Each message consists of: -- -- -- a message descriptor a number of data fields and/or blocks of data fields; a message delimiter.

The message header, which contains the message descriptor, and the message trailer, which contains the message delimiter, are considered to be system, network, or transmission medium-dependent and as a result are not part of this partof ISO 15022. However, the message descriptor and delimiter are considered to be-part of this part"of ISO 15022. A message may be constructed with its data fields and blocks of data fields in any order. This will not change the meaning of the message. 4.3.1 Message descriptor

The data content of each message must be preceded by a message descriptor. The descriptor identifies the scope of the message, the fields that maybe specified and the conditions for their use. The message descriptor information must be included in the header. It consists of up to three sub-fields: a message code, an optional version number and an optional message version sub-format.

IS .15587 (Part 1): 2005 1s0 15022-1:1999
It is recommended cmessage to use the sequence:

code> [<sub-field separato~

<version numbem[ <sub-field separator> cmessage version issuer

code>[cmessage

version issuer sub-code>]]]

,

in the format

The message code (3!c) refers to a message type which defines the scope of the message, e.g. an order to buy. The version number ('7'%l!c)allows different versions of the message type to be supported concurrently. It defines the data fields that may be used in the specific message type. If no version number is specified in the message descriptor, it is deemed to be message type version "000. It should be noted that there may not necessarily be an overall generic message type and version, which encompasses all the other current -versions. The optional message version sub-format ("~4!c[4c]) allows one to create proprietary sub-formats to refine a message type version by, for example, indicating that additional constraints or general usage guidelines apply, e.g. 521 /005/lSITl 997 could indicate that the following message is version five of message type 521, which is used in compliance with the requirements defined by ISITC in 1997. It should be noted that a sub-format is a user defined variation of a message type version and must be fully compatible with this message type version. 4.3.1.1 Message version sub-formats

The Registration Authority (RA) will maintain a list of unique-four-character message version issuer codes. When possible, they will consist of the first four characters of the BIC of the registering financial institution. If no BIC is available, the message version issuer code will be created by-the, RA. Once a message version issuer code has been registered, the message version issuer may then create its own set of message version sub-formats identified by its issuer code optionally followed by a unique four-character message version issuer sub-code of its choice. The RA will check the compliance of the message version sub-format with the related message version. Message version sub-formats are available for use by any user. 4.3.1.2 Version number By default, all existing messages (i.e. lSOTfR 7775 messages)

All new messages are given version numbers. are attributed version number "000".

As stated above, message type alone (e.g. MT 521) identifies a message scope, but not a message format. Hence MT521 just means `receive against payment', and MT521/000 means the lSO/TR 7775 format of MT521. The version number is used in two ways: -- for a new release of an existing version which will be phased out after a transitional conversion period, e.g. users of MT 521/067 decide to adopt a new format for receive against payment, which will be called 521/089; to identify the message formats used by different communities of users for the same scope, e.g. MT521/008 is the current version used by European Custodians, 521/004 is the version used by International Central Securities Depositories (ICSDS), 521/154 is the current version of CREST,...

--

Versions are described in the Catalogue of Messages. They are not proprietary: anybody can use them, e.g. using the above example, DTC can start using 521/154 without asking CREST. One community of users cannot define several current versions of the same message type (except in the case of transition to a new release, as explained above). If a community wants to further identify the variations of the message format in various specific situations, these "sub-formats" may be identified in the third sub-field of the message descriptor (i.e. the message version sub-format). Message version sub-formats are listed but not described in the Catalogue of Messages. To ensure the uniqueness of a sub-format's identification, the message version issuer code must be registered with the Registration Authority.
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IS 15587 (Part 1): 2005 ISO 15022-1:1999 e.g.:
. ,--
521 /007/lSITOOOl 521 /023/DAKV is the sub-format is the sub-format of 521/007 of 521/023 registered registered

by ISITC for a receive against payment instruction;
by Deutsche Borse Clearing

for a receive against

payment instruction; -- 521/O04/CEDEO041 is the sub-format registered by Cedel Bank for a receive against payment instruction between two Cede! members; 521 /004/CEDEO061 is the sub-format registered by Cedel Bank for a receive aaainst . pavment instruction . between a Cedel member and SICOVAM. -

--

All sub-formats of a message version must be fully compatible with the master version format, while the versions of NOTE a message type are normally not fully compatible with each other. 4.3.2

Data field

A data field consists of a field tag, followed by a tag separator and the data item. <field tag> <tag separator> cdata item> A data field will normally only refer to one data element or possibly several related data elements whenlhey need to be combined to represent a meaningful unit of information, e.g. the settlement day + month + year need to be combined to form a meaningful settlement date data field; similarly, the settlement amount is the combination of the currency and the amount of money, because the amount of money alone does not mean anything. On the other hand settlement date and settlement amount are each meaningful units, which may need to be used separately and are thus in separate data fields. A data field may normally only occur once in a message if not in a block. For new data fields, the field tag will uniquely define the format, possible values and meaning of the following data item. Both the field tag and the data item may be divided into sub-fields. 4.3.2.1 Field tag and tag separator

The field tag uniquely identifies the business function and format of the following data item. It may contain one, two or three sub-fields depending on the type of data field. -- Discrete data field

The field tag consists .of a single field type. <field typextag ":''2!@l~] -- Generic data field separatom, in the format: U.n

The field tag consists of two or three sub-fields: a field type, a qualifier, and in certain circumstances a data source scheme. <field type> csub-field separator><quaiifierxsub-field separato~[<data source issuer sub-code>]]<tag separator>, in the format: II:)!2!C[1C] ll::l! 4!C
U*

source

issuer code>[cdata "/"

r

[4!C[4C]]

The field type (":''2!c[1c]) identifies either a specific field (discrete data field) or a class of fields (generic data field). It accommodates the existing lSO/TR 7775 field tags. A typical generic field type would signify a Date or a Party.

9
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The qualifier (4!c) is a four-character code word. Typical qualifiers for the Date generic different types of dates such as Trade, Settlement or Coupon dates. data field would identify

.

The Registration Authority will maintain a list of unique data source schemes. The data source scheme (4!c[4c]) may be only used for certain generic data fields (see Data Field Dictionary). It qualifies the following data item.
EXAMPLE 1 The Start of Block discrete data field has a field type:l 6R, which can be used as follows: : 16R:BLOCKNAME1 EXAMPLE 2 for the beginning of a block called BLOCKNAMEI.

The Date/Time generic data field has a field type:98a, which can be used as follows: :98A::TRADI!19980302 :98A::SE~//l998O3O5 for a trade date of 2 March 1998 for a settlement date of 5 March 1998

EXAMPLE 3

The Party generic data field has a field type:95a. Format option P specifies the BIC code of the party, whereas option R allows a proprietary code (i.e. issuer specific) to be specified as follows: :95P::BUYIWCITIG62L :95R::BUYR/XISM/12345678 for the buyer of securities being Citibank in London. for the buyer of securities being identified by the proprietary code 12345678 a/located by ISMA.

4.3.2.2

Data field status

A data field within a message may have one of the following status in the Catalogue of Messages: --M mandatory; conditional: i.e. may or may not be required, or not allowed, depending on the circumstances as defined in the Catalogue of Messages; optional: the data field should be present when the underlying information exists and is known to the sender. However, the message is meaningful without the data field. Data item sub-field

--c --o
4.3.2.3

The data item within a field maybe divided into various sub-fields. All sub-fields are separated by sub-field separators unless the sub-field consists of a currency and an amount, e.g. USD123,45 JPY1OO15, A data item sub-field maybe either a `code word', a `structured value' or `unstructured text'. The format of a code word is four upper case alphanumeric characters (i.e. 4!c). Examples of structured values include dates, integers and amounts of money. Structured values often have restrictions on the maximum and minimum values and the number of acceptable decimal places. The use of unstructured text fields is discouraged, since their inclusion frequently prohibits straight through processing. A sub-field within a data item can be: -- -- mandatory conditional: i.e. may or may not be required, or not allowed, depending on the circumstances as defined in the Catalogue of Messages; optional: the sub-field should be present when the underlying information exists and is known to the sender. However, the message is meaningful without the sub-field.

--

10
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If a data item consists of three optional sub-fields A, B and C respectively, their presence in the data field must be indicated by the use of separators. Trailing separators are omitted.
EXAMPLE

>

"xiy/z"
"tiy" "x//y" `Ydy" " f, x `Yx" `Vx"

means that A, B and C are present, with values x, y and z respectively. means that A and B, with values x and y respectively, are present, but C is not. means that A and C are present with values x and y respectively, but B is not. means that B and C are present with values x and y respectively, but A is not. means that A is present with value x, but B and C are not. means that only B is present with value x. A and C are not. means that only C is present with value x.

4.3.3

Blocks of data fields

Blocks of data fields are often used to indicate a repeated or related sequence of data fields within a message. For example in a statement of holdings, the information pertaining to each holding may be put in atilock. Similarly a list of certificate numbers would be put in a block. A block of data fields consists of: -- -- -- a start of block field; a number of data fields and/or blocks of data fields; an end of block field,

This implies that blocks may be nested within each other. Blocks may be repeated in a message, but not defined recursively, i.e. a block may not be defined in terms that include itself. If it is required to repeat a data field with the same meaning within a message it should be put in a block. 4.3.3.1 Start and end of block fields

The start of a block is indicated by a special discrete data field with the field type ":16R". The data item consists of the block name optionally followed, for repetitive blocks, by the occurrence in the message and the-total number of occurrences in the message. The format of this data field is: ":16 R:" 16c~/"3n~f'3n]]

where the first sub-field (16c) is the block name. Each block apart from repeated occurrences of the same block must have a unique block name within the message. The optional second sub-field is used for repetitive blocks where it is mandatory. It defines the number of times, including this occurrence, that this block has occurred so far in the message. The first occurrence will have a value of 1, the second 2, etc. The optional third sub-field defines the total number of times the block occurs in the message.
For example, the second occurrence start of block heading:

of a block of data fields called MYDATA which will occur 3 times would have a

: 16R:MYDATAW3
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Associated with every Start of Block is an End of Block identified by the field type ":16S.

The End of Block discrete

data field has the format: ":16S:" 16C ~~3n] .
where the mandatory first sub-field contains the same block name as in the associated start of block data field.

The optional second sub-field defines, for repetitive blocks, the number of times, including this occurrence, that this block has occurred so far in the message. The sub-field is mandatory for repetitive blocks. The value should agree with that in the associated start of block data field.
EXAMPLE 1 (Repetitive block) The following repetitive block of amount information contains two data fields, Amount (field type:19a) and Date (field type:98a). : 16t?'AMoulVT/l : 19A::sEw//usD5ooo, :98A:: VALLW1997102O : 16s:AMouNT/1 : 16R:AMOUNT/2 : 19A::SETT//USD10000, :98A:: VALW19971021 : 16S:AMOUNT/2 EXAMPLE 2 (Non-repetitive block)

If the field type for generic data field Number Identification is:1 3a, a block of certificate numbers could be defined as:
: 16R:CERTIFICATES : 13B::CERT/77+ 1OOOO+C.234691-7 : 13B::CERT//2+ 1000+A. 1572329A. ?671 11 : 13B::CERT//l+ 100+D. 123456 -.

: 16S:CERTIFICATES End of blocks are specified explicitly. They are not implied.

4.3.3.2

Nesting data blocks

Data field blocks may contain other data field blocks. A data field block within another data field block must be completed within the block.
EXAMPLE The following example shows how two small blocks may be nested within a larger block.

: :6R:BIGBLOCK

.....
: 16R:SMALLBLOCW1 . .... Data in first small block :16S:SMALLBLOCK71 : 16R:SMALLBLOCK72 . .... Data in second small block : 16S:SMALLBLOCKZ2

.....
:16S:13/G5LOCK
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4.3.3.3 Data field block status

A data field block within a message, like a data field, may have one of the following status in the Catalogue of Messages: , --M mandatory; conditional: i.e. may or may not be required, or not allowed, depending on the circumstances defined in the Catalogue of Messages; as

--c --o

optional: the data block should be present when the underlying information exists and is known to the sender. However, the message is meaningful without the data block.

The status of a field within a block, only applies if the block exists. A block of data fields does not have to include any mandatoty fields between the start and end of block fields.

5 Data Field Dictionary
The Data Field Dictionary contains information on all registered Enhanced ISO 7775 and EDIFACT fields, as well as on the mapping between the Enhanced ISO 7775 data fields and the equivalent information defined in lSO/TR 7775, ISITC DSTU 1/1995 or SSAB data dictionaries. 5.1 Contents

Each registered field has a unique name and meaning. Only fields that comply with the design criteria are included in the Data Field Dictionary. The following information is included on each data field: -- -- -- -- -- -- Name of discrete data field (e.g. start oftilock) or class of generic data field (e.g. date); Definition of the discrete data field or class of generic data fields; Field type; Format of the data; The valid values that the field may take, e.g. a number between 1 and 99 or a list of code words; If the field can take code words, then all the registered code words together with their meaning, usage, and status should be given. Code words and code values may be added to a field without giving rise per se to a new Data Field Dictionary entqc An example of the use of the field; Rules on how and when to use the data elements in the field. History of the field: -- -- -- -- -- -- when it was created; when it was last updated; whether it replaces another field. .

-- -- --

List of Registered Message types where the field is used; Where appropriate, a list of all the lSO~R Data Field IXctionary status. 7775 synonyms, ISITC or SSAB equivalents for-the data field;
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Sub-fields in Enhanced ISO 7775 are not registered in their own right, although they are described in the relevant field. In the EDIFACT syntax, data elements always need to be registered together with the segment they belong to, although the Data Field Dictionary can be accessed by specifying the data element only. Similarly, in the Enhanced ISO 7775 syntax, blocks of data fields are not registered, although the start and end of block data fields are. The contents of a block are described in the Catalogue of Messages within the registered message in which they occur. The start of block data field entry mentions the block names and the messages where they are used.

5.2

Access

to the Data Field

Dictionary

The access to the ISO 15022 Data Field Dictionary database is provided to interested parties by means of a paper copy, the Internet or agreed substitute network. The access to this database will be organized in such a way that it helps the financial institutions in mapping from to another. It will be possible to access the information via "Syntax", from "Messages" or via "Fields" directly.
one syntax

The Data Field Dictionary will be accessible through Enhanced ISO 7775 and EDIFACT terminology. Reference to lSO/TR 7775 synonyms, SSAB or ISITC equivalents are only made in order to facilitate mapping. A field registered in the Data Field Dictionary is accessible by either its field tag (Enhanced ISO 7775), by a combination of Segment/Data Element (EDIFACT) or by its business name (e.g. date; settlement date). (See Figure 1.)

WEBSITE

Messages

I

I

Syntax (Enhanced

I

-

\~ie,~s/777''E''FAc
Figure 1 -- Access to Data Field Dictionary 5.3

Data Field Dictionary status

Each fietd or value will be allocated a status. The status may take the values: -- -- -- Live"and re-useable; Live but rrot re-useable; To be removed on a specific date.

Specific values (e.g. code words) may be specified as going to be removed at a future date, when the field itself is marked as kve. At least 12 months notice will be given prior to removing a field from the Data Field Dictionary. Fields in registered live messages may not be removed from the Data Field Dictionary before the message is removed from the Catalogue of Messages.
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5.4 EDIFACT-- Enhanced ISO 7775 relationship

>

It should be noted that there can be a difference in notation and format between the Enhanced ISO 7775 and the EDIFACT standard. Moreover, several EDIFACT segments, (composite) data elements and code words do not have an equivalent in Enhanced ISO 7775, e.g. a data segment in EDIFACT could correspond to either a single data field or to a block of fields in Enhanced ISO 7775. Generally, an Enhanced ISO 7775 data field will correspond to an EDIFACT data element within a data segment. In many cases there is a direct one-to-one relationship; in some cases, there is a one-to-many relationship, particularly for composite data fields. By way of example, a settlement date in Enhanced ISO 7775 is a single data field (:98A::SETT//CCYYMMDD), whereas in EDIFACT this would be represented by separate data elements within the DTM (Date Time Period) segment. Similarly, a composite data item in Enhanced ISO 7775 such as in the generic data field Amount (:19A) which consists of two sub-fields (Currency Code and Amount) would map into two separate data elements in the EDIFACT MOA (Monetary Amount) segment. Several EDIFACT segments -- the Service Segments (e.g. Header and Trailer, Security Segments) as described in ISO 9735 -- do not have a correspondence in lSO/TR 7775. Since they are not relevant to the .Data Field Dictionary, they will not be included.

6 Catalogue

of Messages

The ISO 15022 Catalogue of Messages consists of: -- . -- 6.1 Still used lSO/TR 7775 messages, which are registered as version 000 of Enhanced ISO 7775; Enhanced ISO 7775 messages, other than version 000, and their equivalent EDIFACT-messages; EDIFACT messages. Contents

The Catalogue of Messages describes all currently registered versions of all message types. ISO/TR 7775 messages are attributed version number `000. The Catalogue of Messages does not include any sub-format restrictions imposed by an issuer. The message type defines the business scope of the message, e.g. delivery against payment. The version number defines the data fields that may be used (and how) to satisfy this business scope in a particular community of users. A registered Enhanced ISO 7775 message type and version may only contain data fields and/or lSO/TR 7775 synonyms of data fields that are registered as re-useable in the Data Field Dictionary. A registered EDIFACT message type and version may only contain fields that are registered in the Data Field Dictionary or Service Segments as defined in ISO 9735. A new version number will only be created if: . -- -- a new field or fields are required; a field that was mandatory is now conditional or optional; the required conditional structure of fields is incompatible with that in the existing version.

In particular this means that a new version number will not normally be created in the following circumstances: -- -- -- -- a different field order is required (Enhanced ISO 7775 only); a field that was conditional is now mandatory; a field that was conditional is now optional; a field that was conditional is now not allowed;
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-- --
--

a field that was optional is now mandatory; a field that was optional is now conditional; a field that was optional is now not allowed;
only specificcode

--

words or formats are allowed for certain fields.

If an issuer requires a specific sub-format of a message version (i.e. same scope but more specific usage rules), then it should use the appropriate version number qualified by a message version sub-format. It is possible for an issuer to have more than one sub-format of the same message version, and in the case of a new release, more than one version of the same message type, e.g. we could have:
521 521 /004 521/O04/CEDEO041 receive against payment message;

generic version of receive against payment

used by ICSDS;
between

sub-format defined by Cedel Bank for instructions to receive against payment two Cedel members.

In the above example, 521/O04/CEDEO041 is a message version sub-format of 521/004. This message version subformat is fully compatible with message version 521/004. All sub-formats are valid variations of the message version and can thus be pre-validated using the message version validation rules, e.g. any fields which are mandatory in 521 /004 must be mandatory in all sub-formats. 6.1.1 Message description

The description of a message in the Catalogue of Messages will consist of the following clauses Description Details the purpose and the possible usages of the message, OPERATING PROCEDURES and GUIDELINES. with the sub-headings SCOPE, FUNCTIONS,

The subclause SCOPE specifies the purpose and hence the business scope of the message. It positions the message in the entire transaction processing chain, and explains in what situations and between which parties the Message is to be used and not to be used. It does not contain usage guidelines, descriptions of sequences, implicit field rules, or system constraints. The subclause FUNCTIONS amendment etc.). summarizes the different functions (e.g. instruction, cancellation, notification, affirmation,

The subclause OPERATING PROCEDURES explains the business relationships needed to use the Message, such as a reference to bilateral/contractual agreements or legal frameworks. It may also define responsibilities of the sender and the receiver. The subclause GUIDELINES gives further explanation in a less formal way and without the need for being exhaustive. It explains the relationship between the fields representing parties .to the transaction, and explains the different types of transaction flows and instruction types. It also explains the different scenarios covered by the Message and the sequences and fields to be used in what scenario. It may also explain the way the information has been grouped into sequences. Message format Gives the layout of the message in terms of fields and blocks/segments. Wherever possible, new messages are listed with fields in the message or within blocks/segments business order. in a logical

The format of fields in the message which are in the Data Field Dictionary is not included with the message in the Catalogue of Messages, although restrictions on their use are. In the electronic version, there will be a link to the Data Field Dictionary entry. 16
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Fields which are not described in the Data Field Dictionary, t?.g. lSO/TR 7775 synonyms, are described with the message. A reference to the field with which this synonym is associated may be provided in the Catalogue of Messages.

,

Field usage Details any message specific details about the usage of fields, and any conditional rules governing the presence and usage of fields in relation to each other, where this is relevant. The field descriptions themselves are.however not defined in the message but in the Data Field Dictionary. An example is normally given for the main scenarios. Mapping The clause MAPPING explains how to map messages, if applicable. This may refer either to the conversion from an old format into a new one, or to the correspondence between two different messages that are part of the same information flow. 6.1.2 Message status
and versicm numbers

Messages

of messages in the Catalogue of Messages may have the following status.

-- --

Live; To be removed on a specified date.

At least 12 months notice will be given by the Registration Authority before a message "is removed from the Catalogue of Messages. A community of users may notify the `Registration Authority during that timeframe that a messa-ge should be retained. 6.1.3 Message version sub-formats . .

Although sub-formats of message versions are not parl of the Catalogue of Messages, the Registration Authority will maintain and publish a list of message version sub-formats. This list will highlight their functions and issuers. Details of sub-formats will be available from the issuer. 6.2 Access to

the Catalogue

of Messages

Access to the Catalogue -of Messages will be provided to interested parties by means of a paper copy, the Internet or an agreed substitute network. The Catalogue of Messages will be accessible through the Enhanced ISO 7775 or EDIFACT syntax. In the electronic version of the Catalogue of Messages, there will be a link to the Data Field Dictionary.

6.3 EDIFACT -- Enhanced ISO 7775 relationship
In the Catalogue of Messages, all securities messages and their different versions registered under Enhanced ISO 7775 will show the equivalent EDIFACT securities message(s) and their subsets, which will generally refer to a message with a more generic business function registered in the UN/EDIFACT Message Type Directory, if this message has already gone through the UN process. It should be noted that, as far as message design is concerned, the EDIFACT standard tends towards a broader based template approach, whereas the Enhanced ISO 7775 standard enables one to design vety specific messages. Subsets of a message -- equivalent to a `version' in Enhanced ISO 7775 -- are not registered in the UN/EDIFACT Message Type Directory. However, in the Catalogue of Messages, these subsets will be specifically registered and linked to the appropriate version numbers.
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Annex A
(informative)

Message

construction

guidelines

Messages in Enhanced Enhanced

ISO 7775 and EDIFACT

may be constructed

in similar ways,

ISO 7775 message structure

A message is sent from one party to another the message contains a message code which conveys the nature of the message. The version of the message is uniquely identified by the message descriptor. The Message consists of data fields, which mayor may not be grouped into blocks of data fields. Each data field consists of afield type, an optional qualifier and a data item. The field type, qualifier or data item are each considered to be data elements; as such they may be simple or composite. Composite data elements contain sub-fields. Thus a message maybe presented hierarchically in the following manner (separators omitted for clarity): Message Message Descriptor Message Code Message Message Version Number Version Issuer Code

Message Version Issuer Sub-code Block of Data Fields Start of Block Field Start of Block Field Type Start of Block Block Name Statt of Block Occurrence Data Field Data Field Field Type Data Field Qua/ifier Data Source Issuer Code Data Source Issuer Sub-code Data Field Data Item Sub-Field 1 ... -Sub-Fields n End of Block End of B/ock Field End of Block Field Type End of Block Block Name End of Block Occurrence Count Count
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ISO 9735 (EDIFACT) message structure

,

A message is sent from one party to another; the message contains a header segment which conveys the nature of the message. The version of the message is uniquely identified by the message header segment. The Message consists of user data segments, which may or may not be grouped as repetitive or nested segments. Each segment consists of a segment code data element and one or more additional data elements. Data elements may be simple or composite. Composite data elements contain component data elements. Thus a message maybe presented hierarchically in the following manner (separators omitted for clarity):

Message Header Segment Beginning of Message Segment Message Reference Message Identifier Message Message Message Message Type Identifier Type Version Type Release Number Type Controlling Agency Number

Repetitive or Nested Segments Segment exp/icit/y starting repetition or nesting Segment Tag . .

Segment Code Segment Repetition or Nesting ~ndicator Segment Segment Tag Segment Code Data Element Composite Data Element Component . .. Component Segment explicitly ending repetition or nesting Segment Tag Data Element n Data Element 1

Segment Code

Message Trailer Segment Synopsis of Enhanced ISO 7775 and ISO 9735 message structure

Although the terminology in Enhanced ISO 7775 syntax and in ISO 9735 (EDIFACT syntax) is different, the capability and means to hierarchically structure data are similar. Both syntaxes allow for a fixed, small number of hierarchical levels to structure data.
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The following table shows side by side the structural elements of each syntax standard that allow for a similar granularity: . Enhanced Message Block of Blocks Block of Data Fields Data Field Sub-field ISO 7775 syntax ISO 9735 syntax Message Repetition or Nesting of Segments Segment Data element Component Data Element

EXAMPLE 1 A block built according to Enhanced ISO 7775 syntax to specify a party in a securities transaction including an account serviced by this patty can be expressed by an EDiFA CT Fll (financial institution information) segment, following ISO 9735 syntax rules: Enhanced ISO 7775 syntax ISO 9735 syntax Segment

Block of Data Fields

EXAMPLE 2 : 16R:SETPRTY :95P::REAG//DEuTDEFF :97A::SAFE,V123456789 : 16S:SETPRTY Comments: REAG is the qualifier for receiving agent. The party is identified by a B/C (Option P). REA is the qualifier for receiving agent. 25 is the qualifier to specify B/C. 5 is the qualifier to spaci@ ISO as issuer of BICS. FII+REA+ 123456789+DEUTDEFF:25:5'

In the past, dictionaries have been built up according to ISO 7775 and ISO 9735 rules. The rules used to structure data have not been the same. Thus when comparing functionally equivalent data, different patterns can be found.

EXAMPLE 3 For data fields, the Enhanced ISO 7775 generic data field corresponds to a functionally equivalent EDtFACT DTM (date/time/period) segment: Enhanced Data Field ISO 7775 syntax /S0 9735 syntax Segment

EXAMPLE 4 :98A::SETT//l997O9O8 DTM+205: 19970908:102'

Comments:
98A is the option to specifjf CCYYMMDD date format. SE7T is the qualifier for settlement date. 205 is the qualifier for settlement date. 102 is the qualifier to specify CCYYMMDD date format.

The ISO 15022 Data Field Dictionary and its support for both Enhanced ISO 7775 syntax and ISO 9735 syntax through one Registration Authority provides the opportunity for convergence for new fields in the secutiles industry.
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The following message construction guidelines only apply to the Enhanced ISO 7775 syntax:

Messaue tyD es and version numbers ,
Even if a message is intended for private system use, standard message types and version numbers should be used wherever appropriate.

Restrictions

and messaae

version sub-formats

It is possible for a community of users to place restrictions on the acceptable messages, options and Iormats.
For example, -- -- . they may: in the Latin 1 charabter set;

not accept all the characters

only accept specific code words; require a field to be mandatory.

The message type and version numberwill then be further qualified by a message version sub-format. Field order The order of fields in a message or block does not change the meaning of the message. Systems should be designed to process messages with fields in any order. Block structure Although theoretically there should be no limit to the number of levels of nested blocks, for practical purposes it is recommended that this is limited to 9 levels of nesting, i.e. 8 levels of blocks within the outer one. Code words Code words should not be mnemonics, as this maybe confusing and limit the number of possibilities. Optional blocks and fields The number of optional blocks and fields in a message should be minimized as they do not facilitate straight through processing. Default values The use of default values is not recommended. It is advocated that an explicit code value is assigned to represent the desired default value, e.g. `NONE'.
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TECHNICAL CORRIGENDUM 1

Technical Corrigendum >
Committee lSO~C

68, Banking,

1 to parts 1 and 2 of International Standard ISO 15022 was prepared by Technical securities and other financial services, Subcommittee SC 4, Securities and re/atecf

financial instruments.

This International

Standard contains data elements related to dates where the year is formatted in /ess than four digits. The format of these data elements will be considered, and, if appropriate, amended on the occasion of the next revision. Meanwhile, it is recommended that users consider, within the context of their implementation of this International Standard, any requirements for amendment in relation to the year 2000 and their business environment.
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